In the field of electronics, various electronic design automation (EDA) tools are useful for automating the process by which integrated circuits, multi-chip modules, boards, etc., are designed and manufactured. In particular, electronic design automation tools are useful in the design of standard integrated circuits, custom integrated circuits (e.g., ASICs), and in the design of an integrated circuit that may be programmable. Integrated circuits that may be programmable by a customer to produce a custom design for that customer include programmable logic devices (PLDs). Programmable logic devices refer to any integrated circuit that may be programmed to perform a desired function and include programmable logic arrays (PLAs), programmable array logic (PAL), field programmable gate arrays (FPGA), and a wide variety of other logic and memory devices that may be programmed. Often, such PLDs are designed and programmed by an engineer using an electronic design automation tool that takes the form of a software package.
Within a particular electronics design project, a design hierarchy tree is developed using an EDA tool that represents the logic design of the integrated circuit, chip module, board or other electronic design. The design is composed of functional blocks, or design entities, that may be viewed symbolically as being represented in a design hierarchy tree having nodes that correspond to these functional blocks. In the process of creating a design that may be used to program such an electronic device, a compilation of the design produced by the EDA tool is performed. In most cases, the root of the design hierarchy tree (representing the top-level functional block of the design) is the point from which a user compiles the design.
By compiling from the root of the design, all of the lower level design entities within the design hierarchy tree are compiled within the context of the complete design. That is, any values, parameters, assignments or other general design requirements that are specified at the root are applied to any lower level design entity as long as compilation starts from the root. Often it will be desirable for a user to execute a compile at a node below the root in the design tree; however, such a local compilation presents difficulties in the prior art.
In the prior art compilation of such a design tree, a compile is performed from a node that is specified as the root. In fact, some currently available design tools only allow assignments to be specified at the root level. Thus, to perform a compilation at a node in the tree other than the true root, the user must specify such a lower level node as the root, perform a compile, and then change the root specification back to its original value once a compile has been performed. This changing of the specification of the root of the tree is cumbersome, time consuming, and can lead to further difficulties in tracking design requirements.
These further difficulties include failure to account for assignments that are made to the newly designated root from higher level entities in the hierarchy. Obviously, the result of such compilation is somewhat inaccurate because it does not include assignments from higher level entities. That is, if various parameter values and relative assignments are specified at the root level, different compilation results will occur for a particular lower level node depending upon whether that node is compiled locally in isolation, or whether it is compiled within the context of the complete design when compilation begins at the root. If the lower level node is compiled locally, then any parameter values and assignments specified above would not be used, which yields a different compilation result from what would occur if that particular node were compiled within the context of the complete design. In other words, when a local compilation is performed at a lower level node, parameter values and relative assignments from the root or any parent node are not inherited and used by the lower level node being compiled. Thus, during a local compilation, information such as parameter values, logic options, synthesis styles, etc., that has been specified at a higher level node is lost.
Of course, a user could designate a lower level node within the design tree as the root and specify the initial root's assignments at this lower level. Obviously, this presents the user with an extra burden. Further, if the user adds new assignments (not present in the original root) to the new lower level root, these assignments will be lost when the user finishes his or her compile and reassigns the root to the top-level node. Unfortunately, these assignments at a lower level node may be beneficial to the overall design, and as such the user would wish to keep that assignment for the complete design. However, when the user must reassign the root to the top-level node, any local assignments made at lower level nodes are lost.
The inability to make use of higher level information within a design tree when a local compilation is being performed is further exacerbated when using an EDA tool that allows for macrofunctions with parameters and relative hierarchical assignments. Macrofunctions with parameters are helpful for users wishing to create a design that makes use of variable parameters (such as for bus widths, logic flow, etc.). Relative assignments are also useful in that they allow a designer to uniquely specify an assignment for a logic device anywhere in the design. However, because the prior art does not allow lower level nodes within the design hierarchy tree to be compiled within the context of parameter values or relative assignments specified at the root level or some higher level (in the case of relative assignments), these parameter values and assignments are lost when a local compilation is performed.
Therefore, it would be desirable to have a technique that allowed local compilation within the context of the entire design at any node within a design hierarchy.